What issue type does this pull request address?

/kind feature

What does this pull request do? Which issues does it resolve?

Adds an opt-in mergeStrategy field on imports to support recursive deep merge of config sections.

Problem:
When importing a config (e.g., from a git catalog), the current implementation only does a shallow merge at the first level. If both the imported config and the local config define the same section (like dev.api), nested maps are completely replaced instead of being merged.

Example:

# Catalog
dev:
  api:
    labelSelector:
      app: catalog-app
      version: v1
    command: ["/bin/bash"]

# Local config
dev:
  api:
    labelSelector:
      app: my-app

Before: Local dev.api replaces catalog entirely, loses version: v1, command, etc.
After (with mergeStrategy: deepMerge): Maps are deep merged, keeps both app: my-app and version: v1

Solution:
A new mergeStrategy field on each import entry, with two values:

• shallowMerge (default, current behavior): only top-level keys within each section are merged. Existing keys in the local config take precedence entirely.
• deepMerge (opt-in): maps are merged recursively. Arrays and scalars in the local config still take precedence.

imports:
  - git: https://github.com/org/catalog.git
    subPath: devspace.yaml
    mergeStrategy: deepMerge

Merge rules when deepMerge is enabled:

This enables the common use case where organizations maintain a shared catalog in git, and projects only need to override specific values (like labelSelector) while inheriting everything else (ports, sync config, commands, etc.).

Please provide a short message that should be published in the DevSpace release notes

Imports now support a mergeStrategy field. Set mergeStrategy: deepMerge on an import to enable recursive map merging, allowing projects to inherit shared catalog configs while only overriding specific nested values. Default behavior (shallowMerge) is unchanged.

What else do we need to know?

• Fully backward compatible: default is shallowMerge, which preserves the existing behavior exactly. No existing config is affected.
• Mutually exclusive fields are safe: since deep merge is opt-in, users who don't use it are not affected. When deepMerge combines fields that shouldn't coexist, the existing validations in validate.go catch it properly. This is tested explicitly:
  • deployments: helm + kubectl on the same deployment triggers "deployments[x].kubectl and deployments[x].helm cannot be used together"
  • dev: imageSelector + labelSelector on the same dev pod triggers "dev.x: image selector and label selector cannot be used together"
  • Both cases are also tested with shallowMerge to prove no regression (the conflicting field from the catalog is simply ignored)
• Comprehensive test coverage:
  • 11 integration tests via TestImportsDeepMerge (deep merge scenarios, default shallow, explicit shallow, mutually exclusive field validation in both deployments and dev sections)
  • 7 unit tests for deepMerge (edge cases: empty maps, 3-level nesting, type mismatches, nil values)
  • 4 unit tests for shallowMerge
• Schema files (devspace-schema.json, config-openapi.json) regenerated, IDE autocomplete works out of the box
• All existing tests pass